1. Field of the Invention
The invention relates to secure electronic delivery of content, such as music or movies. More particularly, the invention relates to an improved method and apparatus for authenticating external modules.
2. The Prior Art
An important problem in protecting content is making sure that only compliant, authorized software modules are allowed to process the content on the user's computer. For example, the content owners might want to restrict the number of perfect digital copies that the end users can make from a single piece of purchased content. Or, they might want to allow a restricted “preview mode”, where the content (like a song) is delivered for free, but only be allowed to play some limited number of times. Against this desire of the content owners, are armies of hackers who want to figure out how to patch the software modules to disable the restrictions.
Therefore, code authentication becomes a critical problem: determining whether a given software module is intact and compliant, or has been hacked. In the art, authentication is often treated as a cryptographic problem. The standard way to verify authentication is with digital signatures.
Further, even though the electronic industry is enamored with using digital signatures for code authentication problems, the use of signatures is in reality a poor substitute for a robust cryptographic solution for the following reasons. A digital signature resolves itself into a single yes/no decision, i.e., “did the signature match”? A single jump instruction is thereby generated, which, if patched, disables the signature checking. A hacker's job is facilitated by such a simplistic method. Another algorithm for authenticating data files includes the generation and use of what is known as a “signet”. Signets are described in U.S. Pat. No. 6,038,316 and U.S. Pat. No. 5,978,482 assigned to International Business Machines Corporation. These patents are hereby incorporated by reference. Signets are utilized according to the following description to provide a method and system to distribute extrication functions to legitimate users of information that are (1) openly available, publicly computable, and computationally infeasible to invert; (2) use an extremely long decryption key; and (3) only short communication from the authorization center occurs. An authorization center processor receives a user identifying signal value ni, and then responsively creates a corresponding authorization signal ai, called a “signet”, since it shares some properties of a digital signature. The pair (ai, ni) is called a “signet pair”. The extrication function operates on the signet pair to produce a key signal K that may be used to decrypt the digital information. The extrication function is publicly computable. However, it is computationally infeasible to determine how to create a new authorization signal aj for a corresponding user processor identifying signal value nj, or even to create any new valid signet pair wherein a “valid signet pair” is any pair (x, y) in which x is the result obtained by applying the authorization function, or computation, to y. An alternative method offers the feature that, although the signet pair is short, the key produced by the extrication function is long. The combination of having a long key K with the intractability of generating a new signet pair based on previous signet pairs and the extrication function, serves to de-motivate (i.e. by use of a long K) and incapacitate (i.e. the feature of intractability) those who might wish to attempt to become illegitimate or pirate authorization centers. So, IBM's digital signet technology (which generate thousands of bytes that are correct if and only if the signet matches the hash) is far superior to that of an ordinary signature in this application.
The attack that these hackers utilize is that of patching external modules with illicit functions. The hackers then distribute these hacked programs on the Internet. Users search these out and download them, because copying restrictions have been removed that the legitimate programs enforce. For example, last November, a program called “DeCSS” appeared on the Internet. It allowed users to copy DVD videos, something that legitimate DVD video players are forbidden (by license) to do. While DeCSS was an entire application, this invention envisions that it is not necessary for the hacker to provide an entire program. For example, he may be able to replace only a single module within a program to achieve the result he desires. This problem is exacerbated in the modern world, because programs are often comprised, in part, of external modules provided by manufacturers different than the one manufacturing the program. In particular, a system optionally uses these external modules which are loaded by an application on demand. External modules are typically implemented as DLLs under WIN32 or shared object (SO) files on UNIX platforms and are provided by third party manufacturers.
An example for an interaction between an application and external modules is the EMMS, or Electronic Media Management System, end user application and its use of decoder modules. Based on the type of encoding of an album, a decoder module needs to be located and loaded. Once the module is loaded, its externalized functions are called in order to perform the decompression of the audio data.
This example also highlights the security risk of using external modules. Essentially, the application loads and executes untrusted code. In the above example, that code gets access to the encoded audio data. The existence of a published API (like ACM, an Audio Compression Manager published by Microsoft for modules that are transforming an audio stream for decoders) makes it particularly easy for an attacker to replace the external module with a different one which, for example, simply writes the compressed audio data to disk and thereby obtains an in-the-clear copy which could then be distributed on the Internet.
Any authentication technology used for authenticating external modules needs to take into account that the external module remains functional so that it can be used by other applications which do not require a high level of trust, or deploy their own authentication scheme. Consequently, the external module cannot be simply encrypted by the secure application since that would prevent any other application from using it. As shown by the example above, code in external modules should never be executed without first authenticating that module.
Accordingly, there exists a need for overcoming the disadvantages of the prior art as discussed above.